perm filename MSG.MSG[TCH,LSP]6 blob
sn#821900 filedate 1986-07-31 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00047 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00007 00002
C00008 00003 ∂17-Mar-86 2116 RPG Welcome
C00010 00004 ∂20-Apr-86 0959 RPG Chairman
C00011 00005 ∂20-Apr-86 1330 gls@THINK-AQUINAS.ARPA Chairman
C00013 00006 ∂20-Apr-86 1444 FAHLMAN@C.CS.CMU.EDU Chairman
C00015 00007 ∂21-Apr-86 1155 GRISS%HP-HULK@hplabs.ARPA Chairman
C00016 00008 ∂22-Apr-86 0903 FAHLMAN@C.CS.CMU.EDU Ballot: Fahlman for chairman?
C00018 00009 ∂22-Apr-86 1116 RPG Vote
C00019 00010 ∂22-Apr-86 1153 ALAN@AI.AI.MIT.EDU Ballot: Fahlman for chairman?
C00020 00011 ∂22-Apr-86 2028 Moon@SCRC-STONY-BROOK.ARPA Ballot: Fahlman for chairman?
C00021 00012 ∂25-Apr-86 1035 gls@THINK-AQUINAS.ARPA Ballot: Fahlman for chairman?
C00022 00013 ∂27-May-86 0931 FAHLMAN@C.CS.CMU.EDU Where we stand
C00024 00014 ∂27-May-86 1016 DLW@SCRC-QUABBIN.ARPA Where we stand
C00027 00015 ∂18-Jun-86 0959 RPG OOP
C00030 00016 ∂18-Jun-86 1055 FAHLMAN@C.CS.CMU.EDU OOP
C00033 00017 ∂20-Jun-86 0215 FAHLMAN@C.CS.CMU.EDU Guidelines
C00043 00018 ∂20-Jun-86 0222 ALAN@AI.AI.MIT.EDU Volunteer
C00046 00019 ∂20-Jun-86 1145 ALAN@AI.AI.MIT.EDU Guidelines
C00048 00020 ∂20-Jun-86 1218 FAHLMAN@C.CS.CMU.EDU Guidelines
C00050 00021 ∂21-Jun-86 1337 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Guidelines
C00051 00022 ∂24-Jun-86 1122 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Guidelines
C00053 00023 ∂24-Jun-86 2026 FAHLMAN@C.CS.CMU.EDU Guidelines
C00056 00024 ∂05-Jul-86 2138 RPG Lisp Conference
C00058 00025 ∂06-Jul-86 1447 FAHLMAN@C.CS.CMU.EDU Lisp Conference
C00060 00026 ∂14-Jul-86 1233 FAHLMAN@C.CS.CMU.EDU Request for file
C00062 00027 ∂16-Jul-86 1929 FAHLMAN@C.CS.CMU.EDU Voting
C00066 00028 ∂18-Jul-86 1201 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Voting
C00069 00029 ∂18-Jul-86 1626 FAHLMAN@C.CS.CMU.EDU Voting
C00076 00030 ∂18-Jul-86 2156 FAHLMAN@C.CS.CMU.EDU Voting
C00078 00031 ∂19-Jul-86 1114 RPG Voting
C00080 00032 ∂19-Jul-86 2334 ALAN@AI.AI.MIT.EDU Voting
C00085 00033 ∂20-Jul-86 0920 FAHLMAN@C.CS.CMU.EDU Voting
C00093 00034 ∂21-Jul-86 0654 FAHLMAN@C.CS.CMU.EDU Proposals 1 - 4
C00102 00035 ∂21-Jul-86 1408 gls@Think.COM Voting
C00104 00036 ∂21-Jul-86 1509 ALAN@AI.AI.MIT.EDU Proposals 1 - 4
C00106 00037 ∂22-Jul-86 1012 gls@Think.COM Proposals 1 - 4: my votes
C00108 00038 ∂24-Jul-86 1948 FAHLMAN@C.CS.CMU.EDU CL Proposals "in the hands of the technical committee"
C00115 00039 ∂26-Jul-86 1318 RPG Back in the Saddle
C00116 00040 ∂27-Jul-86 1349 FAHLMAN@C.CS.CMU.EDU Making decisions
C00121 00041 ∂28-Jul-86 0858 gls@Think.COM Making decisions
C00123 00042 ∂28-Jul-86 1222 Moon@STONY-BROOK.SCRC.Symbolics.COM My absence
C00125 00043 ∂28-Jul-86 1940 FAHLMAN@C.CS.CMU.EDU My absence
C00129 00044 ∂30-Jul-86 1719 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #1
C00133 00045 ∂30-Jul-86 1719 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Making decisions
C00139 00046 ∂30-Jul-86 1848 FAHLMAN@C.CS.CMU.EDU Making decisions
C00142 00047 ∂30-Jul-86 1339 FAHLMAN@C.CS.CMU.EDU Handout at Lisp Conference
C00150 ENDMK
C⊗;
∂17-Mar-86 2116 RPG Welcome
To: cl-technical@SU-AI.ARPA
...to the world of international standardization. This mailing list
is the forum for private discussions regarding the technical aspects
of the standardization effort. The contents of the messages transmitted
on this list are archived in a private, non-accessible file at SAIL.
If you choose to also archive these messages, please guard their
privacy.
The members of this list are:
rpg
gls%Think.COM
CL-Technical-from-SU-AI@Stony-Brook.SCRC.Symbolics.COM
(= Moon and Weinreb)
Fahlman@cmuc
bawden@mc
bobrow.pa@xerox
rees@mc
griss@hplabs
-rpg-
∂20-Apr-86 0959 RPG Chairman
To: cl-technical@SU-AI.ARPA
Now that things are rolling, I would like to nominate Scott Fahlman as
chairman of this committee. I think we can agree that no one has worked
harder at the development of Common Lisp than Scott, and that we should
unanimously elect him chairman of the technical committee.
-rpg-
∂20-Apr-86 1330 gls@THINK-AQUINAS.ARPA Chairman
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 20 Apr 86 13:30:34 PST
Received: from yon by GODOT.THINK.COM via CHAOS; Sun, 20 Apr 86 16:30:52 est
Date: Sun, 20 Apr 86 16:32 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Chairman
To: RPG@SU-AI.ARPA, cl-technical@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8604201801.AA22752@GODOT.THINK.COM>
Message-Id: <860420163201.4.GLS@THINK-YON.ARPA>
Date: 20 Apr 86 0959 PST
From: Dick Gabriel <RPG@SU-AI.ARPA>
Now that things are rolling, I would like to nominate Scott Fahlman as
chairman of this committee. I think we can agree that no one has worked
harder at the development of Common Lisp than Scott, and that we should
unanimously elect him chairman of the technical committee.
-rpg-
I second the motion.
--Guy
∂20-Apr-86 1444 FAHLMAN@C.CS.CMU.EDU Chairman
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Apr 86 14:43:29 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 20 Apr 86 17:46:08-EST
Date: Sun, 20 Apr 1986 17:46 EST
Message-ID: <FAHLMAN.12200430445.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Chairman
In-reply-to: Msg of 20 Apr 1986 16:32-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
I would like to thank Dick and Guy for the nomination and say that if
elected by the committee members, I am willing to accept this post
through, let us say, the end of 1986 (unless the committees get
substantially reorganized before then through interaction with X3).
Other nominations are certainly in order at this point.
-- Scott
∂21-Apr-86 1155 GRISS%HP-HULK@hplabs.ARPA Chairman
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 11:54:33 PST
Received: from HP-HULK by hplabs.ARPA ; Mon, 21 Apr 86 11:55:00 pst
Date: Mon 21 Apr 86 07:08:06-PST
From: Martin <GRISS%HP-HULK@hplabs.ARPA>
Subject: Chairman
To: cl-technical@su-ai.ARPA
Cc: GRISS%HP-HULK@HPLABS
I vote also in favor of Fahlman
M
-------
∂22-Apr-86 0903 FAHLMAN@C.CS.CMU.EDU Ballot: Fahlman for chairman?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Apr 86 09:01:05 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 22 Apr 86 12:03:30-EST
Date: Tue, 22 Apr 1986 12:03 EST
Message-ID: <FAHLMAN.12200892357.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Ballot: Fahlman for chairman?
Just to make it all official: The proposal is that Scott Fahlman should
serve as Chariman of the Technical Committee though 31 December 1986.
Please vote yes or no by Tuesday, April 29 at the latest.
Though Gabriel and Steele introduced and seconded the motion, I believe
that is not the same as voting yes on it. So far, then, we have what I
take as formal "yes" votes from Bobrow and Griss.
Fahlman abstains.
∂22-Apr-86 1116 RPG Vote
To: cl-technical@SU-AI.ARPA
I vote for Fahlman.
-rpg-
∂22-Apr-86 1153 ALAN@AI.AI.MIT.EDU Ballot: Fahlman for chairman?
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 22 Apr 86 10:27:43 PST
Date: Tue, 22 Apr 86 13:30:00 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Ballot: Fahlman for chairman?
To: Fahlman@C.CS.CMU.EDU
cc: cl-technical@SU-AI.ARPA
In-reply-to: Msg of Tue 22 Apr 1986 12:03 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[AI.AI.MIT.EDU].29870.860422.ALAN>
Yes.
∂22-Apr-86 2028 Moon@SCRC-STONY-BROOK.ARPA Ballot: Fahlman for chairman?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Apr 86 20:28:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 469884; Tue 22-Apr-86 23:27:35-EST
Date: Tue, 22 Apr 86 23:26 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Ballot: Fahlman for chairman?
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12200892357.BABYL@C.CS.CMU.EDU>
Message-ID: <860422232644.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Yes
∂25-Apr-86 1035 gls@THINK-AQUINAS.ARPA Ballot: Fahlman for chairman?
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Apr 86 10:34:54 PST
Received: from THINK-KATHERINE.ARPA by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 21410; Fri 25-Apr-86 13:39:13-EST
Date: Fri, 25 Apr 86 13:36 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Ballot: Fahlman for chairman?
To: Fahlman@CMU-CS-C.ARPA, cl-technical@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12200892357.BABYL@C.CS.CMU.EDU>
Message-ID: <860425133639.5.GLS@THINK-KATHERINE.ARPA>
Yes.
--Guy
∂27-May-86 0931 FAHLMAN@C.CS.CMU.EDU Where we stand
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 May 86 09:31:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 27 May 86 12:11:49-EDT
Date: Tue, 27 May 1986 12:10 EDT
Message-ID: <FAHLMAN.12210057807.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: cl-technical@SU-AI.ARPA
Subject: Where we stand
In-reply-to: Msg of 27 May 1986 10:24-EDT from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
I agree with both suggestions: to keep a separate file of changes and to
label each technical committee decision with a number and/or a date.
-- Scott
∂27-May-86 1016 DLW@SCRC-QUABBIN.ARPA Where we stand
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 May 86 10:16:20 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 2203; Tue 27-May-86 10:22:34 EDT
Date: Tue, 27 May 86 10:24 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Where we stand
To: Fahlman@CMU-CS-C.ARPA, cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12209892202.BABYL@C.CS.CMU.EDU>
Message-ID: <860527102431.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 26 May 1986 21:01 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
technical committee would make a decision. Each such decision is folded
immediately into the manual, which is available online to everyone.
I'd like to suggest that in addition to folding in such changes, we also
maintain an official change history. This would serve as a summary of
all official decisions of the technical committee. It would help
someone answer the questions: (1) what has changed? (2) has there been
an official resolution of this issue?
To help make it clear that these decisions are final resolutions, so
that people can know when to modify their implementations and so as to
terminate trailing flames, I suggest that the changes be numbered
serially. I anticipate some reactions of the form "that's too
bureaucratic" or something, but I think it would save a lot of trouble
in the long run, in keeping the record straight.
∂18-Jun-86 0959 RPG OOP
To: cl-technical@SU-AI.ARPA
This committee might be interested in the activities of LMI.
They are on a road show to talk about a commercial standard OOP.
In particular, they seem to be interested in a kernel OOP
such that the things they want are implementable in it. The basic
flavor of their proposed kernel is CommonLoops, but with some stuff
to implement ObjectLisp. Eric Benson, Patrick Sobalvarro, and I
spent the entire day yesterday with them. The most interesting part
of the day was a discussion of the mis-merits of ObjectLisp.
The LMI folks are trying to arrange a meeting between themselves,
Xerox, and me to discuss this kernel idea. The key interesting point
is that LMI doesn't feel necessarily wedded to ObjectLisp - though they'd
like to retain the ability to have a `current object' - and that they
feel that the companies owe it to the world at large to make a decision
about OOP soon.
At Lucid, we are at the point of requiring an OOP for our own window
system, the case being that we have imlemented as much of it as we can
without making a committment to an OOP. We have flavors, but do not intend
to write our code using it. In the absence of a direction from the
community, we will simply adopt CommonLoops, though there will be a
Rosetta Stone phase in which we attempt to put down some documentation for
it by reading the code, talking to Gregor, and sacrificing chickens.
-rpg-
∂18-Jun-86 1055 FAHLMAN@C.CS.CMU.EDU OOP
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jun 86 10:55:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Jun 86 13:55:21-EDT
Date: Wed, 18 Jun 1986 13:55 EDT
Message-ID: <FAHLMAN.12215843982.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-technical@SU-AI.ARPA
Subject: OOP
In-reply-to: Msg of 18 Jun 1986 12:59-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
It has been clear to me since Boston that ObjectLisp was not a
contender. This is on its merits, and has nothing to do with which
companies have chosen to back it. When I describe ObjectLisp to people,
about 10% say "Hmmm...interesting" and about 90% make a sour face and
barfing noises. So I'm glad to hear that LMI insn't inseparably wedded
to this system.
In case I didn't say it clearly before, I'm now feeling pretty strongly
that what we want is a standard object-oriented system that is complete
enough to be usable on its own (but with some things available as
extensions) and not a set of hooks that will allow a thousand flowers to
bloom. It is now a bit late in the game for the idea of "let's put in
the hooks and experiment for a couple of years." As Dick's note
indicates, various groups are going to be locking in decisions pretty
quickly now.
-- Scott
∂20-Jun-86 0215 FAHLMAN@C.CS.CMU.EDU Guidelines
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jun 86 19:44:02 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 19 Jun 86 22:43:55-EDT
Date: Thu, 19 Jun 1986 22:43 EDT
Message-ID: <FAHLMAN.12216202375.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Guidelines
The following is essentially the "guideline" proposal that I sent around
before. Aside from Fry's opinion that we should do a lot of renaming
and argument shuffling in order to make the language more consistent, I
have heard no dissenting opinions. I would like to say that the
technical committee has accepted these guidelines. Please read the
following and let me know soon if you have any objection. Let's not get
bogged down tuning the language too finely on this, unless there's
something that really bothers one of you -- these are guidelines, and
not a contract.
-- Scott
---------------------------------------------------------------------------
As we develop a new language definition for Common Lisp, which we intend
to propose as an official standard, an important question is how much we
are willing to change the existing Common Lisp dialect, as described in
"Common Lisp: the Language". The following guidelines have been
accepted by the technical commitee:
Despite its imperfections, Common Lisp is already a standard. Nearly
every U.S. company with a presence in the AI market has announced some
sort of support for Common Lisp (though not always to the exclusion of
supporting other Lisps). There is similar interest in Japan among those
companies not totally committed to Prolog and some interest in Europe.
It is now our goal to turn Common Lisp from a de facto standard into an
official one. In the process, we have the opportunity to clarify those
things that are currently ambiguous (and which therefore weaken the
standard), to fix some problems that defeat the purpose of the standard
(e.g. problems that make it hard to write portable code), and to finish
defining some essential parts of the language that we left unfinished in
the rush to complete CLtL.
There are a number of implementations on the market, and many more in
the pipeline. There are many hundreds of active users, and this number
is growing very fast. A number of large software systems and AI
toolkits have been ported to Common Lisp, and again this is an
accelerating trend. All of this says that there is a very large
investment in the existing language; by the time a standard could be
approved, this investment will be much larger.
The existence of a large and fast-growing user community cuts two ways.
On the one hand, for every change that we consider, we must think about
not only the merits of making the change, but also the cost in terms of
code that must be changed and users who must be retrained. On the other
hand, if a change is unavoidable, the sooner we make it, the smaller the
cost.
Different kinds of changes have different kinds of costs:
Compatible extensions cost the users nothing (except that they make an
already complex language more complex). The cost is to the various
Common Lisp implementors who have to put the extension into their
respective products. If the extension is rather small, or if it will be
easy to implement (perhaps because someone supplies a public-domain
implementation of the extension), then we can consider the proposal on
its merits alone. If the extension requires some significant
implementation to make a lot of fundamental internal changes, then the
threshold is considerably higher.
In the case of true ambiguities (where implementors really have chosen
divergent interpretations, and not just where some clever fellow can
find a loophole in the language of CLtL), it is generally worthwhile to
make a clear choice, even though one group or another is going to have
to fix things. In some cases it will be appropriate to explicitly allow
both interpretations, but not where this tends to interfere with
portability of code.
Changes that affect a lot of existing user code should not be made
unless there are VERY strong reasons for doing so. Changes that would
break things in subtle ways are the worst -- something like changing the
type of NIL, for example, would break all sorts of things. Changes to
particular functions, which can be searched for by name and fixed in
straightforward ways, are not quite so bad. Changes to obscure corners
of the language that only concern a small minority of users are not so
bad, especially if the change benefits that small community and is
favored by them. For example, if there's some subtle issue about
roundoff that should be changed in order to make the number crunchers
happy, we could consider this.
In general, changes that affect only the implementors are less costly
than changes that affect all sorts of user code; there are fewer groups
that have to make changes, and they have more resources for doing so.
We must not overburden the implementors with changes or it will cause
delays and disruptions, and it could conceivably lead to a schism, but
we believe that a moderate number of small changes will not be resented
if the changes are made for good reason. From the time a change is
approved until the time it becomes part of some Official Standard will
be on the order of a year. That's plenty of time to make the changes
and to build and test a new version, even for the most ponderous of
companies.
There's a lot of interest in improving code portability, settling on a
workable error system, and trying to agree on an object-oriented
programming facilty (or foundation for one). If any of these goals
requires some change, that probably counts as a good reason. At this
point, mere aesthetic considerations are not sufficient to justify an
incompatible change.
∂20-Jun-86 0222 ALAN@AI.AI.MIT.EDU Volunteer
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 19 Jun 86 22:42:52 PDT
Date: Fri, 20 Jun 86 01:43:04 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Volunteer
To: RPG@SU-AI.ARPA
cc: cl-technical@SU-AI.ARPA
In-reply-to: Msg of 18 Jun 86 1002 PDT from Dick Gabriel <RPG at SU-AI.ARPA>
Message-ID: <[AI.AI.MIT.EDU].59350.860620.ALAN>
Date: 18 Jun 86 1002 PDT
From: Dick Gabriel <RPG at SU-AI>
I will do EVAL-WHEN.
I -think- I'm very interested in the EVAL-WHEN issues. They seem to be
related to a number of other puzzling problems that have been plaguing the
Lisp world recently, such as the problem of properly scoping the
identifiers returned by a macro, and the problems surrounding ``top-level''
forms. They all involve the ``meta-processing'' of a program.
As far as I know, no Lisp dialect has ever tried to be careful about the
code that describes this meta-processing. (Except 3LISP, which I suppose I
will go and look at again, but I don't recall that it seemed like a good
solution the first time I read it.) It would be nice if CL could get this
right.
Of course it may turn out that this can not be adaquately addressed within
CL, due to other constraints we have already built in to the language, in
which case I would be less interested. But I'm optimistic. Unlike the
EuLisp people, I think the CL evaluator is straightforward (boy are they
ever confused about -that-!), so I don't think that it will get in our way
on this one.
So, although I'm perfectly happy for you to get to work on this one,
if you would like to bounce something off of me early in your thinking, you
could be assured of my enthusiasm.
∂20-Jun-86 1145 ALAN@AI.AI.MIT.EDU Guidelines
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 20 Jun 86 11:45:41 PDT
Date: Fri, 20 Jun 86 14:45:54 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Guidelines
To: Fahlman@C.CS.CMU.EDU
cc: cl-technical@SU-AI.ARPA
In-reply-to: Msg of Thu 19 Jun 1986 22:43 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[AI.AI.MIT.EDU].59561.860620.ALAN>
I have no objections to the sentiments expressed in this document. Who are
these "guidelines" for? Is this a kind of press-release for the
consumption of users and implementors so that they will get a warm feeling
about the technical committee? Or is this a constitution we are adopting
that will be used in the future to guide our behavior and settle our
disputes?
∂20-Jun-86 1218 FAHLMAN@C.CS.CMU.EDU Guidelines
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jun 86 12:18:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 20 Jun 86 15:18:12-EDT
Date: Fri, 20 Jun 1986 15:18 EDT
Message-ID: <FAHLMAN.12216383375.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Cc: cl-technical@SU-AI.ARPA
Subject: Guidelines
In-reply-to: Msg of 20 Jun 1986 14:45-EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
"Constitution" is a bit too strong, but I view these guidelines as
something that we or others in the design discussions can point to and
say "Look, this proposed change is too radical according to the
guidelines we have adopted." That doesn't mean we don't do it, but it
does mean that anyone proposing to violate the guidelines must make a
convincing case why it is justified. So the idea is more or less to set
a default level of conservatism that we all agree to, more or less.
Without this, we'd have someone like Fry arguing that we should
rationalize all the function names in order to make them look better.
-- Scott
∂21-Jun-86 1337 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Guidelines
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 21 Jun 86 13:36:17 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26585; Fri 20-Jun-86 10:27:53 EDT
Date: Fri, 20 Jun 86 10:31 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Guidelines
To: Fahlman@CMU-CS-C.ARPA, cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12216202375.BABYL@C.CS.CMU.EDU>
Message-ID: <860620103101.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Modulo fine-tuning of language, this looks fine to me.
∂24-Jun-86 1122 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Guidelines
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 24 Jun 86 11:16:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28176; Mon 23-Jun-86 16:17:25 EDT
Date: Mon, 23 Jun 86 16:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Guidelines
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12216202375.BABYL@C.CS.CMU.EDU>
Message-ID: <860623161638.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
The guidelines you mailed out are okay with me. I think before
publishing this a bit more description of what it means in practice
for the cost of a change to be large or small should be included;
this would be something like a description of the process, where
"small" changes would be adopted easily if they have merit, whereas
"large" changes would have to survive some more elaborate process.
They way I've just described it is poor, and I don't think I would
agree with it myself if phrased that way. I think I saw a better
description go by in the mail in the past few days, but I can't
find it now. Perhaps you have it.
∂24-Jun-86 2026 FAHLMAN@C.CS.CMU.EDU Guidelines
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 24 Jun 86 20:26:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 24 Jun 86 23:25:54-EDT
Date: Tue, 24 Jun 1986 23:25 EDT
Message-ID: <FAHLMAN.12217520739.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-technical@SU-AI.ARPA
Subject: Guidelines
In-reply-to: Msg of 23 Jun 1986 16:16-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
The guidelines you mailed out are okay with me. I think before
publishing this a bit more description of what it means in practice
for the cost of a change to be large or small should be included;
this would be something like a description of the process, where
"small" changes would be adopted easily if they have merit, whereas
"large" changes would have to survive some more elaborate process.
They way I've just described it is poor, and I don't think I would
agree with it myself if phrased that way. I think I saw a better
description go by in the mail in the past few days, but I can't
find it now. Perhaps you have it.
I'm not sure what "better description" you might be talking about. I
thought that the definitions of "big" and "small" changes was spelled
out sufficiently in the guidelines, and that the only difference in
procedure would be the degree of reluctance that we technical committee
members feel in agreeing to changes. I trust us be duly influenced by
this. Do you really want this set up more formally?
-- Scott
∂05-Jul-86 2138 RPG Lisp Conference
To: cl-technical@SU-AI.ARPA
CC: rhh@MC.LCS.MIT.EDU
I think that the EuLisp people would like to meet with the Common Lisp
people on Tuesday night. However, Tuesday night is the night for the
speakers' and organizers' banquet, but I think that the Common Lisp/EuLisp
meeting should go on at the same time.
I might not be able to be there the whole time, but I can possibly slip
away after a speech and a quick bite. Bert Halstead is, I think, finding a
room for the EuLisp meeting, so we can use that room (?) If not, I can get
another (if MIT has none, Symbolics will).
The object-oriented programming meeting should take place around 2pm on
Wednesday. I'll ask Halstead to plan a room at MIT.
-rpg-
∂06-Jul-86 1447 FAHLMAN@C.CS.CMU.EDU Lisp Conference
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Jul 86 14:47:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 6 Jul 86 17:47:41-EDT
Date: Sun, 6 Jul 1986 17:47 EDT
Message-ID: <FAHLMAN.12220604896.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-technical@SU-AI.ARPA, rhh@MC.LCS.MIT.EDU
Subject: Lisp Conference
In-reply-to: Msg of 6 Jul 1986 00:38-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Dick,
The object-oriented meeting should be announced as soon as possible,
since it is open and since its timing after the end of the conference
may impact travel plans. I assume that you and Bert will announce
this meeting as soon as it is firm enough. If the time is now firm,
that could be announced in advance of finding a room.
-- Scott
∂14-Jul-86 1233 FAHLMAN@C.CS.CMU.EDU Request for file
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Jul 86 12:31:51 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 14 Jul 86 15:31:35-EDT
Date: Mon, 14 Jul 1986 15:31 EDT
Message-ID: <FAHLMAN.12222677258.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Request for file
Does anyone have an online version of Guy's proposed changes from the
Boston meeting? I've got hardcopy, but it would save me time if I had
a copy of the file online, and mine seems to have disappeared. I'd like
to merge this into the Issues file tonight if anyone can mail me a copy
by then. Thanks.
-- Scott
∂16-Jul-86 1929 FAHLMAN@C.CS.CMU.EDU Voting
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Jul 86 19:29:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 16 Jul 86 22:28:31-EDT
Date: Wed, 16 Jul 1986 22:28 EDT
Message-ID: <FAHLMAN.12223277460.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Voting
Before the first batch of issues is voted on by the technical committee
(us), we'd better decide what the rules are. Possibilities range from
the very cautious to the very quick. On the cautious side, we could
leave an issue on the table until we've heard from everyone on the
committee and until we've either reached unanimity or it is clear that
we are not going to converge. That could take a long time, especially
if someone goes on vacation or gets buried by other work for awhile.
On the quick side, I could toss out proposals with my recommendation and
say that the recommendation will become law unless someone on the
committee complains within a week, in which case we'll have an internal
discussion followed by a vote. We'd be able to move fast that way, but
maybe too fast.
Let me propose an intermediate system:
When a proposal is officially submitted to the commitee (with a
recommendation), it will not become an official decision until (a) a
majority of the members of the committee (5 out of 8) have explicitly
voted in favor of it AND (b) one week has passed. Furthermore, if
during the week anyone on the committee objects to the majority
decision, we will withhold any decision for a second week while the
person objecting tries to persuade others of his view. After two weeks,
the majority rules unless the members of the majority agree to a allow
the decision to be delayed for further study and debate. Obviously, if
we take the two-week option on two many things, we're either going to
take twice as long to decide all this or we'll have to consider issues
in larger batches.
All of this would be done via the Cl-Technical mailing list so that we
don't get randoms introducing lots of noise into the process. However,
we may occasionally decide to take an issue back to the larger list in
order to sample community opinion on some issue that comes up and that
wasn't argued to death already.
Opinions?
-- Scott
∂18-Jul-86 1201 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Voting
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jul 86 12:00:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45218; Fri 18-Jul-86 14:54:37 EDT
Date: Fri, 18 Jul 86 14:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Voting
To: cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12223277460.BABYL@C.CS.CMU.EDU>
Message-ID: <860718145441.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
One week, or even two weeks, is a preposterously short time for
making decisions that will affect this language for years to come.
You're being totally unrealistic, in my opinion. I think you
ought to multiply the two time periods in your proposal by a factor
of at least five, preferably more.
By the way, I have not yet read any of the mail sent to the Common-Lisp
mailing list during July, except for a few short ones, and I will not
be able to do so for another week. When I counted them two days ago
there were 59 unread messages. It would be grossly irresponsible of me
to whip through those messages in a hurry, instead of saving them for
a time when I am able to give them the careful consideration they deserve.
I expect there are other people both on the technical committee and on
the general common-lisp mailing list in the same boat.
So I don't even know yet what these proposals are that you're talking
about, never mind having an intelligent opinion about their merits and
their possible effects on diverse implementations of the language.
∂18-Jul-86 1626 FAHLMAN@C.CS.CMU.EDU Voting
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jul 86 16:26:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 18 Jul 86 19:26:18-EDT
Date: Fri, 18 Jul 1986 19:26 EDT
Message-ID: <FAHLMAN.12223768559.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-technical@SU-AI.ARPA
Subject: Voting
In-reply-to: Msg of 18 Jul 1986 14:54-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Well, that's pretty disappointing. I was hoping that if I jumped in and
did all the moderating, all the proposing, all the bookkeeping, and all
the writing on the new document (accepting, but not really depending on,
any offers of help), then the rest of you could at least keep up with
the reading and could vote on, say, five specific proposals per week if
they are small ones. Maybe that was too optimistic. Several of you did
warn me that you had real jobs that would require a certain fraction of
your time.
For the record, the ISSUES.TXT file now contains 37 proposals from
Steele's list that I believe are not very controversial (though I'm sure
we'll get a few people making random suggestions on each), 27 relatively
simple proposals on issues that have been raised since December, 24
relatively simple proposals that are likely to requires some discussion
and serious thought, 13 smallish issues waiting for proposals, and 10
big issues requiring complex proposals. Many of the things in the first
two categories have been discussed before and argued to near consensus;
the "likely to require some discussion" things were dropped with no real
convergence.
If we set aside the big things (object-oriented programming, errors,
eval-when, and so on) and we assume that someone comes up with
reasonable proposals for the smaller issues that need them, and asuming
some small amount of growth in the set of issues, then we've got to
decide maybe 70 easy questions and 40 harder ones. Suppose we bundle a
couple of the easy issues in with each of the hard ones. That give us
maybe 40 batches of issues to decide. If we give each batch five weeks,
that comes to about four years. And then we can start arguing about
errors and objects and the rest of the hard stuff. I can guarantee that
if we move at that pace, none of our decisions will be affecting
ANYTHING for years to come. Common Lisp might survive, but it will be
no more standard than it is now.
If the rest of the technical committee is equally overloaded, we'll have
to rethink this whole thing. Maybe instead of voting on these things a
few at a time, at the end of a period of debate, I should just whip
ahead trying to resolve these things, putting proposals with
recommendations onto the list, and when all 110 of them are on there,
then we ask the technical committee to approve the whole thing or to
send a few issues back for reconsideration. I might be able to get this
all done by December, and then the rest of you could take however long
it takes to make a decision. Of course, that would mean that there is
no feedback from the technical committee to the community until the
process is over.
Or maybe we shouldn't try to decide individual proposals officially.
I'll ask for guidance, write a spec acordingly, and then we'll have a
big vote on the spec.
Or maybe we should just hang it up and admit that this sort of thing
can't be done by a committee, and maybe it can't be done at all.
The rest of you should let me know what you want to do about this. I
can put in a large amount of work for a while, maybe as much as a year,
but when it comes to making decisions we all have to be involved, or so
goes the current theory.
-- Scott
∂18-Jul-86 2156 FAHLMAN@C.CS.CMU.EDU Voting
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jul 86 21:56:09 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 19 Jul 86 00:56:22-EDT
Date: Sat, 19 Jul 1986 00:56 EDT
Message-ID: <FAHLMAN.12223828654.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Voting
In-reply-to: Msg of 18 Jul 1986 14:54-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Until we get this voting business sorted out, I intend to keep raising
issues on the mailing list, discussing them, turning them into specific
proposals, and finally "submitting the proposals to the technical
committee". That means putting the proposals on a list for now, and
we'll try to make decisions at whatever rate we decide is feasible.
I suppose if there gets to be a huge backlog of proposals, I suppose
we'll have to declare a moratorium on raising new issues or turning old
issues into proposals. But I'm afraid that if we stop now, we'll never
regain what little momentum we've been able to generate in the last few
weeks, and people will give up on us altogether.
-- Scott
∂19-Jul-86 1114 RPG Voting
To: cl-technical@SU-AI.ARPA
I think that Scott's proposals for timely voting are acceptable in
principle, once we get to the voting stage. I presume that there is a
lengthy discussion phase (such as is going on regarding various topics
right now on Common-Lisp) preceding the voting. One of the provisions of
the favored proposal ought to be to allow members of this committee to
`beg off' and extend discussion.
Many of the issues to be decided are trivial, and lengthy discussion
should be discouraged. I think we're in a position to recognize the
difficult decisions and to not hasten too much.
Moon's comment is important, but he could have as easily made that comment
in response to a legislative body about to adopt Robert's Rules. If we
allow indefinite debate, the result of our deliberations will be elegance
or nothing; we might as well join the EuLisp group. When time is limited
by decree, perhaps we serve the real world better, because we will always
have the clock to help us measure the urgency of our decisions.
Therefore, I second Scott's intermediate proposal, with the added
provision that any member can request a discussion delay on any
issue.
-rpg-
∂19-Jul-86 2334 ALAN@AI.AI.MIT.EDU Voting
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 19 Jul 86 23:34:19 PDT
Date: Sun, 20 Jul 86 02:35:31 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Voting
To: cl-technical@SU-AI.ARPA
Message-ID: <[AI.AI.MIT.EDU].72922.860720.ALAN>
I suspect that what Moon is objecting to is the thought that he will read
his Common Lisp mail after a week of hacking on something else and discover
that last week something like one of KMP's error system proposals has been
moved to the cl-technical stage and now he has one day left to decide on
its merits.
Given that I have been batching my consumption of Common-Lisp mail by
reading through my archive about once every -two- weeks, I think I agree
that the proposed rate is too quick. In addition, I think it is perhaps a
bad idea to start the voting pressure too close to the introduction of the
topic to the cl-technical mailing list. I would much rather there was a
period where we could exchange views on this mailing list before there was
very much pressure to vote.
I suggest that Scott's proposal for voting procedure be adopted, but with
the original period lengthened to a month, and the automatic extension
(granted to anyone who demands it) lengthened to an additional two weeks.
For hard issues it should not be considered unusual for us to decide (by
consensus, majority opinion, or chairman's decision) to extend the debate
even beyond a month and two weeks, or to send the issue back to the general
list for reconsideration.
This should give is plenty of time to clarify the issues among ourselves
where necessary before having to vote. And it should give enough breathing
room to people whose schedules and work habits make it impossible to deal
with these issues every single day.
If there really is going to be a problem with the throughput of this
committee, then we can deal with more issues per batch. I see no need to
increase the frequency of the batches to the point where they fly by so
quickly that you can miss one by taking a few days off. If I have just
proposed that we take 4 times as long with each batch, then I'm happy to
deal with batches that are 4 times as big.
Recall that in 1981 we considered 233 issues in one large batch (none of
them really requiring more than a few paragraphs discussion, I admit). It
took me a couple of days of concentrated labor to work through that entire
list, but I'm certain I prefer that to dealing with 4.5 issues a week for
52 weeks. Even if I could have theoretically gotten my week's work done in
a couple minutes every Sunday afternoon.
[ All this talk of mailing list parliamentary procedure reminds me of the
time I agreed to play a game of Nomic (introduced in one of Hofstadter's
Scientific American columns) by network mail. Technically the game is
still in progress, although progress has been pretty slow given that one
player has stymied the game by refusing to vote for the last three
years.... ]
∂20-Jul-86 0920 FAHLMAN@C.CS.CMU.EDU Voting
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jul 86 09:20:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 20 Jul 86 12:20:43-EDT
Date: Sun, 20 Jul 1986 12:20 EDT
Message-ID: <FAHLMAN.12224215384.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Cc: cl-technical@SU-AI.ARPA
Subject: Voting
In-reply-to: Msg of 20 Jul 1986 02:35-EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Well, my model was that most of us would follow and participate in
the technical debates taking place on the Common Lisp mailing list as
they happen, and that there would not normally be any need for a
separate period of technical debate just among ourselves. Issues would
go to the "technical committee" when the community, including us, seems
to have converged. That's the way it has worked in the past.
Given that model, the decision making by the technical committee is
mostly a matter of rubber-stamping an existing consensus (which we have
already participated in forming), and occasionally making hard decisions
where the community has deadlocked and someone has to decide. The
rubber-stamp issues could fly by pretty fast, and on the harder ones
we'll have done most of the arguing already and there won't be much more
to say before voting.
Another function is to take a last look at the proposals and make sure
that, in their final form, they make sense, but if we were to spot any
problems, my view is that the public discussion should be re-opened on
that issue, not that we should do a lot of debugging and tuning behind
closed doors and present the community with decisions that they have not
seen in advance. Again, it was my hope that the "last call for
comments" period (always at least a week long) could be used for this
purpose.
All of that would work well, I think, and would not take a lot more of
anyone's time than any other way of doing it, but it does require that
most of us keep up with the ongoing discussion (within a few days) most
of the time. If people really feel that they must batch up Common Lisp
activities and give this stuff a burst of time every month or two, the
above model can't work. In that case, I guess the only choices are to
submit proposals in large batches, with 4 - 6 weeks of decision time for
each batch, or to pipeline the thing, submitting a small bunch of issues
every week, but not expecting a decision on any given bunch until 4 - 6
weeks after it is submitted.
The problem with both of those models is that it totally separates the
activities of the technical committee from those of the community at
large. When the community is debating some issue, they won't have the
benfit of our feedback (except for mine). Then, when the community
believes that something has basically been settled by consensus, the
issue disappears into limbo for a long time and nobody can count on the
answer. If we end up rubber-stamping the decision, fine. But in many
cases, if we high-powered experts look at some issue for the first time
weeks after everyone else has finished with it, one of us will spot a
problem. Then we either present the community with a decision that is a
total surprise to them or re-open the public debate. (And if we do not
follow this second debate in real-time, we iterate again, 4 - 6 weeks
later.)
I realize that the volume of mail has been very great in the last couple
of weeks. I've been trying to whip the community into some sort of
movement, and haven't wanted to be too authoritarian in telling people
to shut up when they start arguming among themselves about an
alternative that is clearly not going to be accepted. My feeling is
that as the process starts rolling, some of this will simmer down, but I
could be wrong.
If there's some way I could make it easier for the rest of you to follow
the debates in real-time, we could try that. Some of you have appointed
assistants who would follow the debate, filter the important mail to
you, and flag anything that wants your immediate input. If it would
help (and only if, since it's still more work for me to do), I could
send out a terse summary of the worthwhile points that have been raised
at the time of the "last call for comments". Those of you who choose to
could read that instead of all the rambling messages and discussions of
issues not related to the cases at hand. If a couple of others on the
committee are reading all the mail, they could flag any unjustified
omissions in my summary. Note that I would only send this to the
Cl-Technical mailing list. If this were sent to Common-Lisp, it would
be politically impossible for me to say that "X suggested solution Y,
which clearly is a loser" or just to ignore X's suggestion altogether.
I've already received some flames for the little "the consensus seems to
be" summaries that I've put out with the proposals.
-- Scott
∂21-Jul-86 0654 FAHLMAN@C.CS.CMU.EDU Proposals 1 - 4
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jul 86 06:54:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 21 Jul 86 09:55:01-EDT
Date: Mon, 21 Jul 1986 09:54 EDT
Message-ID: <FAHLMAN.12224451008.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Proposals 1 - 4
Just in case you don't want to fetch the proposal file, here are
proposals 1 - 4 with my recommendations.
---------------------------------------------------------------------------
Proposal #1: Error signalling (7/21/86)
This is a proposed change, upward compatible from the user's
point of view:
Create three levels of errors: Class 1 errors must be deteced and
signalled by any legal implementation. Class 2 errors must normally be
detected and signalled, but implementations may choose to omit the error
testing and signalling in code compiled with an OPTIMIZE SAFETY value of
0 or 1; in this case, the behavior if the error occurs is unpredictable,
and perhaps fatal to the Lisp. Class 3 errors are considered to be
errors, but it is left to the discretion of the implementor whether and
under what conditions Class 3 errors are detected and signalled.
There will be a usage note indicating that portable code should not
depend for correct operation on Class 2 errors being signalled, since
under some conditions of compilation they will not be.
Note: CLtL has classes corresponding to Class 1 ("signals an error") and
Class 3 ("is an error"). We intend to propose that certain errors,
including wrong number of arguments to a function, array references out
of bounds, and certain wrong-type errors, be moved from Class 3 to Class
2. However, such proposals will be discussed individually, after an
error system has been adopted. The decision at this point is whether we
should use the three-level error system as the working assumption in
future discussions.
[I (sef) favor this, but suggest that we change "OPTIMIZE SAFETY value
of 0 or 1" to read "OPTIMIZE SAFETY value of 0". It was pointed out
that the default SAFETY is 1, and checking should be required unless the
user specifies otherwise.]
---------------------------------------------------------------------------
Proposal #2: Argument List Information (7/21/86)
Proposed Extension:
(FUNCTION-PARAMETERS <function>)
Takes one argument which must be a function, not a macro or special
form.
Returns the following six values:
1. Number of required parameters in the function's lambda list.
2. Number of optional parameters in the function's lambda list.
3. T if the function's lambda list contains the &REST lambda-keyword;
NIL otherwise.
4. T if the function's lambda list contains the &KEY lambda-keyword;
NIL otherwise.
5. A list of all keywords accepted by the function, in arbitrary order.
This list may be pre-stored, so it should not be destructively
modified by the user.
6. T if the function's lambda list contains the &ALLOW-OTHER-KEYS
lambda-keyword; NIL otherwise.
If return value 4 is NIL, 5 and 6 must also be NIL.
[I (sef) favor this.]
---------------------------------------------------------------------------
Proposal #3: Argument List Information (7/21/86)
Two alternatives to choose from:
#3A:
Proposed extension:
FUNCTION-PARAMETER-RANGE (function)
The argument must be a function, not a macro or special form. Returns
two values, the minimum legal number of arguments and the maximum legal
number of arguments. If the function's argument list contains &rest or
&key, the second return value is NIL, meaning that there is no maximum
number of arguments.
- OR -
#3B:
Modification to proposal #2:
Add an implementation note to FUNCTION-PARAMETER recommending that
implementations detect calls that will not use the 5th value, and that
they compile such calls in a way that will not cons up a keyword list.
[I (sef) favor 3A, but could happily live with 3B.]
---------------------------------------------------------------------------
Proposal #4: Argument Name Information (7/21/86)
Proposed extension:
(FUNCTION-PARAMETER-NAMES <function>)
Takes one argument which must be a function, not a macro or special
form.
This function returns the names of the parameters to a function, as
specified in the argument list, if such information is available. An
implementation may choose to provide this information for all functions,
only for some, or for none. The final return value specifies whether
the information is in fact available. If this is NIL, the other return
values will also be NIL.
Returns four values:
1. A list containing the symbols naming the required parameters, in order.
2. A list containing the symbols naming the optional parameters, in order.
3. A symbol naming the rest parameter, if any.
4. T if the information returned by this function is valid; NIL otherwise.
Note: This function is included primarily for the convenience of users and to
provide a uniform interface for portable debugging tools.
[I (sef) oppose this. After a period of discussion the community was
unable to agree on the format for returning this information, and there
is no compelling reason to standardize this.]
---------------------------------------------------------------------------
∂21-Jul-86 1408 gls@Think.COM Voting
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Jul 86 14:08:26 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 17:08:18 edt
Date: Mon, 21 Jul 86 17:09 EDT
From: Guy Steele <gls@Think.COM>
Subject: Voting
To: Fahlman@C.CS.CMU.EDU, cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12223277460.BABYL@C.CS.CMU.EDU>
Message-Id: <860721170902.4.GLS@BOETHIUS.THINK.COM>
The proposed voting procedure is acceptable to me. I propose that the
chairman be allowed to exercise some common-sense discretion in the
cut-off dates; for example, if a cutoff date should happen to fall on a
long holiday weekend such as for Thanksgiving or Christmas, it gets
moves to start of the following week.
--Guy
∂21-Jul-86 1509 ALAN@AI.AI.MIT.EDU Proposals 1 - 4
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 15:09:00 PDT
Date: Mon, 21 Jul 86 18:10:22 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Proposals 1 - 4
To: cl-technical@SU-AI.ARPA
In-reply-to: Msg of Mon 21 Jul 1986 09:54 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[AI.AI.MIT.EDU].73475.860721.ALAN>
#1 - No. I would want to know what errors go in what category before
deciding on the categories. This should wait for the error system
proposal.
#2 - Yes.
#3 - A.
#4 - No. It's not clear what this function is for, so I don't see how we
can decide anything about what values it can possibly return.
∂22-Jul-86 1012 gls@Think.COM Proposals 1 - 4: my votes
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 22 Jul 86 10:12:28 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Tue, 22 Jul 86 13:12:36 edt
Date: Tue, 22 Jul 86 13:13 EDT
From: Guy Steele <gls@Think.COM>
Subject: Proposals 1 - 4: my votes
To: cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224451008.BABYL@C.CS.CMU.EDU>
Message-Id: <860722131319.4.GLS@BOETHIUS.THINK.COM>
#1: YES, as amended by SEF. I would prefer to leave two levels
(0 and 1) for the unsafe state and two (2 and 3) for the safe
state with respect to this, so that implementors could distinguish
other things for each case. However, the requirement that 1 be
the default value is persuasive. (I might recommend deleting this
requirement, but prefer not to stir things up.)
#2: YES
#3: YES for 3A
#4: NO. I favor having a way to get at this information, but this
proposal isn't the best way.
--Guy
∂24-Jul-86 1948 FAHLMAN@C.CS.CMU.EDU CL Proposals "in the hands of the technical committee"
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 19:48:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 24 Jul 86 22:48:03-EDT
Date: Thu, 24 Jul 1986 22:47 EDT
Message-ID: <FAHLMAN.12225378159.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: cl-technical@SU-AI.ARPA
Subject: CL Proposals "in the hands of the technical committee"
In-reply-to: Msg of 24 Jul 1986 19:10-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Thursday, 24 July 1986 19:10-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
To: Fahlman
cc: JAR at MIT-MC.ARPA, Moon at SCRC-STONY-BROOK.ARPA,
DLW at SCRC-STONY-BROOK.ARPA, KMP at SCRC-STONY-BROOK.ARPA
Re: CL Proposals "in the hands of the technical committee"
I don't think you've allowed appropriate time for discussion of these
issues on the open list.
I did not have time to respond to these. Please don't take my silence as
consent. You've picked a very busy and awkward time (conference season)
to try to force decision-making through. I spoke with Moon and Rees
privately to find out if you were acting unilaterally in your
presentation of these proposals and selecting a cut-off date or acting
as the voice of the committee and it's my impression that they were as
surprised as I that you were trying to run things in this way.
Even though I don't agree with some of the proposals (which as I say, I've
not had time to reply to), I definitely concur that it's good to have your
proposals on the table in concrete form so that we can debate them usefully.
What I'm objecting to here is your sense of timing.
I let everyone know when I sent out the first set of proposals what sort
of pace that I thought was appropriate and I received no complaints.
Maybe people were already swamped by then. (Moon complained about my
proposed schedule for technical committee voting, but that as a
different issue.) I think that this time of year is no different from
any other -- every time is bad for someone. The real issue is whether
we wait to hear from everyone who might be temporarily buried, or try
to make decisions and move on. That's a tough one.
I'm prepared to listen to suggestions from anyone about the timing of
all this, and about how things should be run in general. All I ask is
that you first look carefully at the ISSUES file and think hard about
how long this will take under any schedule you care to propose. I think
we have one year at the most to do whatever cleanup we are going to do
for the first version of the standard, including such things as errors
and objects. If we must resign ourselves to taking longer than that,
that's OK, but in that case someone else will have to run the show.
The current way of doing all this is not working very well. Maybe the
technical committee should decide things secretly among ourselves, then
divulge the result for a period of public comment, then hide again to
make final decisions. Maybe we shouldn't focus on individual issues,
but should write up a spec with the changes marked and argue about that.
Maybe we need a discussion list that is moderated, so that people can't
drag us off on a tangent twice a day and so that DCP and NGALL get no
more than two screenfuls of comments a day. (They've contributed
considerable good stuff along with lots of randomness, so I don't want
to stifle them.)
I have no desire to be a dictator about any of this, but I can easily
see us taking another month to decide how long it is going to take us to
decide how long it is going to take us if someone doesn't try to flog
things along a bit.
-- Scott
∂26-Jul-86 1318 RPG Back in the Saddle
To: cl-technical@SU-AI.ARPA
I'm back from my trip and saw the notes regarding JIS. If
JIS is the proper Japanese standards organization and if
this working group is properly qualified by JIS, then I
believe we should go ahead and invite Ida (finally). Perhaps
Bob Mathis knows the exact nature of JIS and can quickly
bring us up to date.
Ida will be at the Lisp conference, and we can chat with him
then, assuming his english permits.
I believe that the note inviting Ida should neither precede nor
be preceded by a note to a European representative.
-rpg-
∂27-Jul-86 1349 FAHLMAN@C.CS.CMU.EDU Making decisions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 13:49:02 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 16:49:18-EDT
Date: Sun, 27 Jul 1986 16:49 EDT
Message-ID: <FAHLMAN.12226099291.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Making decisions
So far, I've received votes from Steele, Bawden, and myself on proposals
1 - 4. The rest of you are encouraged to vote, whenever you are ready.
Since we couldn't agree on voting rules, no decision will be announced
until I've heard from ALL of you. However, I don't think that this is a
viable policy for the long run; any one person could bring the whole
process to a halt, just by not reading mail for a while.
I've received Moon's mail pointing out how far behind he had fallen in
mail-reading and suggesting that we take 5 - 10 weeks to make decisions.
Those of you who have caught up on Common Lisp mail have seen that I
just took some steps to limit the volume of mail on random side-issues.
I don't know how well this will work.
Feedback on that or other procedural matters is always welcome. I would
prefer to make group decisions on issues of this kind, but in the
absence on any feedback from the rest of you I will do what I think is
necessary until I am either deposed or I can't take it any longer. I'm
not going to sit back and watch this whole thing unravel for lack of
decisive leadership. If you think I'm out of control, I would be
delighted to turn this job over to someone else.
I have received no suggestions from anyone after my reply to Moon in
which I pointed out that we have a lot of issues to cover and asking
what kind of pace for the decision process might get the job done, while
not disrupting people's schedules. I can't tell if you people are
waiting to see how the current process evolves, if you've given up on
the whole thing, or if you're all so far behind in your mail reading
that none of this has reached you.
I've received word via KMP that Moon and Rees disagree with the pace I'm
setting on the public mailing list. This is not my favorite way to get
feedback. If you're unhappy, please tell me directly.
I'm hoping that we can agree on a reasonable decision-making procedure
and pace by mail, or perhaps by face-to-face discussion in Boston. I
guess there's no time when we could all meet in Boston to discuss this
among ourselves. I'm sure I'll be seeing some of you one-on-one and
maybe we can work out some of these problems then, if you're not reading
mail in real time.
The reason we've got such a backlog of work is because we have gone for
two or three years without any offical decision-making mechanism. Now
we've got one, supposedly: this committee. We really do need to decide
things this time around before they unravel again. There's no point in
doing all this work to get issues into some kind of decidable state if
we're not going to make decisions.
-- Scott
∂28-Jul-86 0858 gls@Think.COM Making decisions
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 08:57:54 PDT
Received: from kant by Godot.Think.COM via CHAOS; Mon, 28 Jul 86 11:58:10 edt
Date: Mon, 28 Jul 86 11:58 EDT
From: Guy Steele <gls@Think.COM>
Subject: Making decisions
To: Fahlman@C.CS.CMU.EDU, cl-technical@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <FAHLMAN.12226099291.BABYL@C.CS.CMU.EDU>
Message-Id: <860728115859.7.GLS@KANT.THINK.COM>
This is just to indicate that I have received your mail, I am reasonably
up-to-date, and I think you're doing a great job of pushing on things.
Keep it up!
--Guy
∂28-Jul-86 1222 Moon@STONY-BROOK.SCRC.Symbolics.COM My absence
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:19:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66802; Mon 28-Jul-86 13:27:19 EDT
Date: Mon, 28 Jul 86 13:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: My absence
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12223768559.BABYL@C.CS.CMU.EDU>
Message-ID: <860728132605.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I have begun reading Common-Lisp mail again. There are 314 messages
at present, with more arriving daily. If we assume an average of 10
minutes a message (and that's assuming quite a high proportion of
messages dismissed out of hand without thinking about them seriously),
it will take 50 hours to process the lot. Even though I now will be
able to spend some time on this, it seems unlikely that I will catch up
on the backlog before the Lisp conference.
I don't know how the rest of you do it. Maybe you don't.
∂28-Jul-86 1940 FAHLMAN@C.CS.CMU.EDU My absence
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 19:39:49 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 28 Jul 86 22:40:07-EDT
Date: Mon, 28 Jul 1986 22:40 EDT
Message-ID: <FAHLMAN.12226425300.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: My absence
In-reply-to: Msg of 28 Jul 1986 13:26-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Reply to Moon:
I have begun reading Common-Lisp mail again. There are 314 messages
at present, with more arriving daily. If we assume an average of 10
minutes a message (and that's assuming quite a high proportion of
messages dismissed out of hand without thinking about them seriously),
it will take 50 hours to process the lot. Even though I now will be
able to spend some time on this, it seems unlikely that I will catch up
on the backlog before the Lisp conference.
I think that the summaries I sent out for issues 5 - 13 (with summaries
on issue 14 and declaration scoping rules to follow) should be helpful.
If you read those first, maybe you can skip or skim the huge number of
messages that led up to the summary.
The mailing list etiquette messages that RPG and I sent seem to have
helped a little bit. At least, half of the Clisp messages I received
today are to me alone, and only a couple will result in mailing list
traffic. Now if we can find some way to tranquilize David C Plummer and
Larry Masinter, we might get mail volume down to a reasonable level. I
don't suppose that there's a joint Symbolics/Xerox technical center in
Rangoon to which these guys could be assigned? Each occasionally has
something useful to say, but they are both so determined to get in the
last word on every issue that we have a nasty race condition... I
hesitate to suggest that we start ignoring their mail, but it may come
to that.
I plan to ask people to observe a moratorium on Common Lisp mail for a
period around the Lisp conference. It won't be 100% effective, of
course, but should keep us from returning to find 500 new messages.
Good luck in catching up. I'll help however I can.
-- Scott
∂30-Jul-86 1719 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #1
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86 17:19:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52897; Tue 29-Jul-86 22:36:33 EDT
Date: Tue, 29 Jul 86 22:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #1
To: CL-Technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224451008.BABYL@C.CS.CMU.EDU>
Message-ID: <860729223629.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
In general I favor the idea of defining the OPTIMIZE SAFETY declaration
to actually mean something, instead of leaving it totally vague. However,
I have two complaints about this proposal which lead me to vote against it.
(1) The proposal means very little in the absence of any specifics about
which errors fall into which categories. If the proposal is nothing
more than "If SAFETY = 0, implementations should not pay as much
attention to error checking as they would otherwise", how is this
different from what CLtL already says on page 160? I don't think it's
necessary or useful to adopt this proposal in its current form; instead
there should be proposals that specific errors are to be detected or not
detected at specific settings of the safety switch.
(2) If we are going to classify exceptions to the language more
precisely, it is important that we separate the two types of exceptions
that are now amalgamated into "is an error". One is errors that are
illegal in all Common Lisp dialects, but are considered too expensive
for some or all implementations to detect. The other is loopholes that
are provided to allow some Common Lisp dialects to make extensions.
On the issue of how many levels there should be, mentioned by at least
Steele and Plummer, I suggest that an implementation that requires
additional levels should relax the requirement that the quantity be
of type (MEMBER 0 1 2 3), and instead use (NUMBER 0 3) or perhaps
(NUMBER * *), i.e. (AND NUMBER (NOT COMPLEX)). The Common Lisp
specification should suggest this as an implementation technique.
Quantities outside of (MEMBER 0 1 2 3) could not be meaningful
in a portable program, so I don't think that it's necessary to require
all implementations to accept arbitrary noncomplex numbers here.
∂30-Jul-86 1719 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Making decisions
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86 17:19:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52910; Tue 29-Jul-86 23:57:03 EDT
Date: Tue, 29 Jul 86 23:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Making decisions
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226099291.BABYL@C.CS.CMU.EDU>
Message-ID: <860729235700.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 16:49 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I've received Moon's mail pointing out how far behind he had fallen in
mail-reading and suggesting that we take 5 - 10 weeks to make decisions.
....
I have received no suggestions from anyone after my reply to Moon in
which I pointed out that we have a lot of issues to cover and asking
what kind of pace for the decision process might get the job done, while
not disrupting people's schedules. I can't tell if you people are
waiting to see how the current process evolves, if you've given up on
the whole thing, or if you're all so far behind in your mail reading
that none of this has reached you.
I think you missed my point. If I was as busy all the time as I have
been for the last three weeks, I obviously would have to withdraw from
the technical committee. The month of July was an exceptionally busy
time for me. Other months are busy for other people. The point is that
the amount of their time people are able to devote to Common Lisp
varies. Not everyone is working on it full-time the way you are. My
suggestion was to allow enough time to elapse after bringing up an issue
and before making a decision on it to smooth out the unevenness in
available time and make sure that everyone has a chance to develop an
intelligent opinion before a decision is made. This does -not- mean
that you have to bring up one issue, shut up for ten weeks, and then
bring up the next issue. My suggestion need not affect the rate at
which decisions are reached at all, it just means that each issue should
remain on the table for a longer time and therefore there will be more
issues on the table at any one time. It's called buffering.
Having thought about it more, I think five weeks is too little time to
decide a substantive issue. Ten weeks is pushing it, but will probably
work if we do a later review of the document to catch any mistakes that
fell through the cracks.
I've received word via KMP that Moon and Rees disagree with the pace I'm
setting on the public mailing list. This is not my favorite way to get
feedback. If you're unhappy, please tell me directly.
I think the problem is not so much a matter of pace, as of your
(perceived) dictatorial attitude that no one else's opinion matters. I
know you well enough to be reasonably confident that this is not your
real attitude, and I doubt that you even realize that your messages
radiate this tone, but this is typical of the way that electronic mail
amplifies misunderstandings. Have you seen the paper by Shapiro and
Anderson on the subject, which proposes some psychological reasons why
this happens and offers some countermeasures? If you haven't, I can
send you a copy.
∂30-Jul-86 1848 FAHLMAN@C.CS.CMU.EDU Making decisions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 18:44:16 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 30 Jul 86 21:44:31-EDT
Date: Wed, 30 Jul 1986 21:44 EDT
Message-ID: <FAHLMAN.12226939466.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-technical@SU-AI.ARPA
Subject: Making decisions
In-reply-to: Msg of 29 Jul 1986 23:57-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
OK, that's what I wanted clarified: given a 5 to 10 week latency, how
much pipelining you think is sustainable.
KMP seemed to be complaing specifically about the pace, though he has
complained since then about my dictatorial attitude and oppressive
rules. Yes, if Shapiro and Anderson have good suggestions on how to
minimize misunderstandings in netmail, I would very much like to read
this. If you could send me a copy, that would be appreciated. (CS
Dept., Carnegie-Mellon Univ., Pittsburgh PA 15213)
I have now reluctantly reached the conclusion that the current system
for deciding things is a total failure, and it cannot be fixed by minor
tuning. I will be sending a more comprehensive message to the technical
committee later on tonight suggesting some possible alternatives.
-- Scott
∂30-Jul-86 1339 FAHLMAN@C.CS.CMU.EDU Handout at Lisp Conference
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 13:39:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 30 Jul 86 16:39:34-EDT
Date: Wed, 30 Jul 1986 16:39 EDT
Message-ID: <FAHLMAN.12226883945.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Handout at Lisp Conference
We plan to hand out the following informational flier at the Lisp
Conference registration. People who read it here won't have to take
one.
---------------------------------------------------------------------------
STATUS OF COMMON LISP STANDARDIZATION EFFORTS
Common Lisp is fast becoming a de facto standard for Lisp, especially in
the commercial world where the need for a standard, widely accepted Lisp
dialect has long been felt. Almost all Lisp suppliers in the U.S. now
offer, or intend to offer, implementations of Common Lisp. The language
is now available on most of the workstations and mainframes that are
used by the AI research community. Several Japanese companies have also
been active in Common Lisp development, and a Japanese standardization
committee has been established. Common Lisp is being used in Europe,
and the European efforts at Lisp standardization are taking Common Lisp
as one important input.
At a meeting in Boston in December, 1985, representatives from the
Common Lisp community agreed to form technical and steering committees
to work on Common Lisp standardization. The technical committee is to
develop a detailed language specification for Common Lisp; the steering
committee is to work on the non-technical aspects of the standardization
process. A group of people, including five key contributors to the
original Common Lisp design, was chosen to select the members for these
new committees; that task was completed in March of 1986.
The technical committee members are Alan Bawden, Daniel Bobrow, Richard
Gabriel, Martin Griss, David Moon, Jonathan Rees, Guy Steele, and Scott
Fahlman (chairman). The steering committee members are Richard Gabriel,
John McCarthy, Ronald Ohlander, Stephen Squires, Guy Steele, and Robert
Mathis (chairman). It is expected that some non-U.S. members will be
added to both committees in the near future. Both of these committees
are interim bodies that will be integrated into the normal standards
process, once that process is operating fully.
A formal proposal was made to X3, the accredited U.S. standards
committee for information processing systems, to establish a technical
committee for Common Lisp standardization. This proposal was accepted;
the Common Lisp committee is called X3J13. Plans are also being made
for the establishment of an international committee for Lisp
standardization under ISO. The formation of an X3 technical committee
is the normal way for the U.S. to participate in ISO activities.
Most of the technical discussion on Common Lisp occurs on the ARPAnet
via the mailing list "common-lisp@@sail.stanford.edu", administered by
Richard Gabriel (rpg@@sail.stanford.edu). A number of other networks
have mail gateways to the ARPAnet, making it possible for almost all
interested parties to participate in the technical discussions.
Electronic mail communication has been established with participants in
Japan and Europe.
The first meeting of X3J13, the U.S. Technical Committee for the
standardization of Lisp, will be Tuesday and Wednesday, September 23 and
24, 1986, in Washington, DC, at the headquarters of CBEMA, Suite 500,
311 First St, NW. On Tuesday (23) the meeting will be from 10am to 5pm;
on Wednesday (24) the meeting will be from 9am to 3pm. No special hotel
arrangements are being made.
Membership in X3 technical committees is open to all who actively
participate (attend meetings or correspond) and pay an annual service
fee (about $175). US citizenship or residency is not required. The
first meeting is important since policies and procedures for X3
technical committees will be discussed and specific plans for the Lisp
activity will be made.
Anyone interested in joining X3J13, and particularly anyone planning to
attend the first meeting, should contact the convenor for X3J13: Dr.
Robert Mathis, 9712 Ceralene Dr., Fairfax, VA 22032. Phone: (703)
425-5923. Arpanet: mathis@@b.isi.edu.
∂30-Jul-86 2220 FAHLMAN@C.CS.CMU.EDU Enough!
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 22:20:06 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 31 Jul 86 01:20:28-EDT
Date: Thu, 31 Jul 1986 01:20 EDT
Message-ID: <FAHLMAN.12226978775.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Cc: fahlman@C.CS.CMU.EDU
Subject: Enough!
On the basis of the experiences of the last month, I have come to the
conclusion that the current design/decision-making procedure is not
working and that it cannot be fixed by small adjustments -- at least,
not by any adjustments that I can think of. I've obviously made a lot
of mistakes as moderator, but I think that the process itself is
unworkable, with or without mistakes.
I would like to bounce some ideas off the rest of you, and then discuss
what to do about all this when I see you at the conference. (I'll be
off the net starting noon on Friday -- a couple of days of family stuff
before the conference.) The mail volume seems to have simmered down
considerably, but that's just because I've stopped pushing ahead toward
decisions. Any introduction of new issues, new summaries, or a move
toward a final decision would re-start the mail storm. I won't be doing
anything like that until we've figured out how to proceed.
The current procedure is basically the kind of open debate that worked
rather well in the early days of Common Lisp. The only fundamental
difference is that when everyone has had their say, there is a technical
committee that is supposed to make the final decision, rather than
having the self-appointed gang-of-five doing it.
In my view, we have at most a year in which to do whatever we are going
to do. We have many (150?) silly little simple things to fix up, a
couple of dozen things of more importance, and a few very large areas
that need a major cleanup and/or a new proposal. On the little things,
what we decide is much less important than THAT we decide (though a few
of these things have had nasty traps buried within). We need to think
these issues through, apply SOMEONE's design taste, settle things, and
move on. Not to decide is to decide.
Given that over-riding need to make simple decisions at a reasonable
rate, the open design discussion has been a disaster. Following
Weinreb's suggestion that we try some easy issues first, just to get the
process moving, I started with a bunch of those. Ten may seem like a
lot, but I suspect that if only the eight of us had been involved, we
would have settled all of these things in acceptable ways very quickly.
Instead, the result is what you have seen: we have spent several weeks
arguing about the order of arguments and returns, whether certain
functions are useful enough to include, and whether certain useless
cases should be declared to be errors or given arbitrary meanings. The
one important issue on the table (declaration scoping) has been swamped
by the noise. Perhaps I should have started with more important things,
but I strongly suspect that if we had put something important like an
error proposal on the table, the same people would be arguing about the
same kinds of stupid details.
As a result of this plague of nit-picking, we have generated enough mail
to drive many reasonable people away rom the discussion, and those of us
who have kept at it have wasted weeks of time on issues that should have
been settled quickly, one way or the other. The volume of Common Lisp
mail has been great enough at times to seriously disrupt other work on
the SU-AI machine. I have been working very long hours on this, and
I've been afraid to take a break lest things unravel totally. This is a
pace I cannot sustain for long. I am still willing to put in a lot of
time on Common Lisp, if I can see that all the work is leading
somewhere, but I am not willing to waste much more time the way we have
been. My increasingly draconian measures intended to steer or slow down
this runaway truck have stirred up a lot of resentment, but have not had
the desired effect. It's just not working.
The problem, in my view, is that we've got too many people assuming that
no Common Lisp issue, no matter how small, can be decided until (a) they
have had their say, (b) all of their points and objections have been
answered to THEIR satisfaction, and (c) they have decided to accept the
ultimate solution. This can never work -- not with hundreds of people
on the list. When we come down to matters of design taste, we need to
pick some small group to make the decision, and the others will just
have to live with it; the obvious small group is the technical
committee. The others get to offer suggestions and point out problems,
but they don't get a veto (except on issues that can be shown to screw
someone in a serious way).
I see three possible ways to proceed:
1. If the rest of you feel that the current process is basically
workable but has been mismanaged, and if a new moderator can be found, I
would be overjoyed to turn over the job to someone else. I would of
course make available all of the materials I have gathered and help the
new person get started; then I would retire to the country and tend bees
(or maybe do some AI research).
2. We adopt a totally diferent set of rules for the debate, making clear
that the technical committee is going to decide all of these little
issues after receiving suggestions from the community. Since this
message is already very long, I will describe one possible set of rules
for this in another message, to follow soon. I would be willing to
continue as moderator under such a new set of rules, though I would also
be delighted to step aside; a new moderator might get the new decision
system off to a cleaner start, with fewer old resentments.
3. If we cannot make these decisions in an open forum, and if the
community is unwilling to trust the technical committee to do the job,
then it's time to admit that we are not going to develop a new standard
for Common Lisp any time soon. We'll have to admit that CLtL is the
closest thing to a standard that we are ever going to have. We should
stop wasting our time and go work our respective Lisp systems and other
worthwhile pursuits. At least, that will be my course of action if
things go this way.
As I said, this is something that I would like to discuss with the rest
of you at some length. I've made too many decisions on my own lately.
-- Scott
∂31-Jul-86 0010 FAHLMAN@C.CS.CMU.EDU Proposed new rules
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86 00:09:45 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 31 Jul 86 03:10:11-EDT
Date: Thu, 31 Jul 1986 03:10 EDT
Message-ID: <FAHLMAN.12226998748.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Cc: fahlman@C.CS.CMU.EDU
Subject: Proposed new rules
Here's a plan that might work and might allow us to spend our time on
the issues that are most important. Alternative ideas are certainly
welcome.
---------------------------------------------------------------------------
There would be a three phase process:
1. Proposals would be generated, discussed, and debugged by the
technical committee alone. Basically, this would be the kind of
discussion we've been having on the Common-Lisp list, but only the
committee members (plus our "assistants") would be involved. Various
members of this group could volunteer to develop proposals for the
various issues, large and small, on the agenda. It would be up to us,
as a group, to spot the problems and to decide all the little details in
a reasonably tasteful way.
In formulating and debugging these proposals, we may occasionally poll
the community to see how they would feel about certain proposed changes;
we may choose to discuss proposals with other people in the community;
we may refer certain issues to subcommittees containing outside members.
The community may inject issues into the process via the moderator or
any other committee member, but we will raise these issues at our own
rate and in an order chosen by us.
The key point is that we don't go public with a proposal until we
collectively have decided (by whatever voting rules we adopt) that it is
something we are ready to approve and put into the spec.
2. Once a proposal has received preliminary approval from the technical
committee, we send it (perhaps along with some rationale) to the
Common-Lisp mailing list for a period of public comment, with a stated
cut-off date. For the simplest issues, the time for comment might be,
say, two weeks; for more complex or lengthy proposals, the time would be
longer.
The critical difference between this and the current system is the
nature of this comment period. The technical committee has tentatively
approved the measure, and will make the decision on final approval.
This is the community's chance to influence the final decision. Their
arguments are addressed to us, not to one another, and the discussions
cannot drag out forever.
We must make clear that the technical committee will pay very close
attention to any claim that the proposed measure will create serious
problems for some implementation or some body of existing code. We will
also pay very close attention to claims that the measure is ill-defined
or unworkable. However, on matters of design taste, people may suggest
amendments, but it is entirely up to the technical committee to decide
which suggestions to adopt. We don't have to argue with people about
this, refute their arguments, or make them happy.
3. When the comment period ends, the technical committee considers the
comments and decides what to do. We might approve the proposal, reject
it, or put an amended version out for a new period of comments. If in
the middle of a comment period someone finds a fatal flaw in a proposal,
we might put a revised version out right away and restart the clock. No
measure will be approved until it has weathered at least a
minimum-length (two week or whatever) comment period in its final form.
Eventually, when enough issues have been settled, we will begin to put
out sections of the new design document for people to comment on.
Similar rules would apply. There will be a final vote of X3J13 (whoever
that ends up being) to accept or reject our work, so we can't run
completely amok.
---------------------------------------------------------------------------
Do you think it would fly?
I see two kinds of problems: first, we might not be able to agree on
some thing ourselves. But there are only eight of us with votes (plus
maybe some foreigners in the future) and we're all reasonable people who
have been at this gme long enough to have some perspective. We wouldn't
need anything like the fascist rules that have been necessary on the big
mailing list. Our internal discussions wouldn't generate so much mail
traffic.
A much more difficult problem is whether the community would buy this.
It is a retreat from our stated goal of having most of the technical
discussions in the open. I expect that some of the people who have been
very active in the recent discussions are not going to like this at all;
they want to have their say on every detail, and we're taking most of
that away from them. (That's the object of the change, of course.)
These people probably will not go legalistic on us, since most of them
work for companies that are represented on the technical committee, but
they probably will complain bitterly.
More problematical are the companies that are not represented on the
committee, and that are paranoid about that situation. They're not
going to want us to go off and decide things without them, and they may
not believe that we're going to take seriously any complaint of the form
"this will screw my company in the following way..." If those guys
decide to block this, they could play very rough.
Well, that's the best I've been able to come up with. As I said, I
cannot handle the moderator's duties under the current rules, so a
change of some sort is going to occur. See (some of) you in Boston.
-- Scott
∂31-Jul-86 1936 RPG How bad is it?
To: cl-technical@SAIL.STANFORD.EDU
Scott seems pretty bummed at how things are going. I think we are making
progress. We have heard many comments on issues 1 - 4, our current issues
of attention. I had presumed that we would let the masses make comments,
we would discuss things among ourselves after we've heard enough, and then
we would decide, letting the masses comment on the decisions. Issues 5 -
13 are being discussed. We are just now getting a good pipeline working,
and the technical committee has partly voted. The only two things going
wrong are that people on the technical committee are swamped with the
usual midsummer woes and that the flamers on Common-Lisp are swamping the
SAIL mailer.
I've had experience with calming mail-senders down. I insult and threaten,
and pretty soon they reform; then it's a cycle.
Ignoring that, we're in fine shape. Scott should simply keep those
proposals going out, stop moderating; and we discuss things among
ourselves more than on Common-Lisp.
-rpg-